Modern computer software applications are often distributed among computer systems and require ability to access and exchange information with other remotely operating software applications. Such exchanges of data and access to functionality often take place over a computer network such as a local area network or a wide area network such as the Internet. Due to the complexities and varying mechanisms of implementing functionality and data formats within modern software applications, software developers often employ software commonly referred to as “middleware” that provides a standardized mechanism for the exchange of information and access to functionality among two or more remotely operating software programs. Middleware is generally connectivity software that consists of a set of enabling services that allow multiple processes running on one or more machines to interact across a network.
Middleware allows a software developer to create a software application using calls to a middleware-specific application programming interface or API in order to insulate the software developer from having to know the details of how to access the remotely operating software application and associated remote data structures or objects. By incorporating a set of middleware-specific function calls into the application under development, the software developer relies on the middleware transport and data access mechanisms and does not need to be concerned with details such as creation of connections to remote computer systems. Middleware is thus software that connects otherwise separate applications or separate products and serves as the glue between the applications. Middleware is thus distinct from import and export features that may be built into one of the applications. Developers often refer to middleware “plumbing” because it connects two sides of an application and passes data between them. For example, there are a number of middleware products that link a database system to a web server. This allows a user application to request data from the database using forms displayed on a web browser, and it enables the web server to return dynamic web pages based on the user application's requests.
One example of commonly used middleware architecture is called CORBA. CORBA is an acronym for Common Object Request Broker Architecture. The CORBA environment is an industry standard that is maintained by Object Management Group, Inc. (OMG) of Needham, Mass., USA. As described on OMG's web site, CORBA provides a vendor-independent architecture and infrastructure that computer applications use to work together over data networks. Using standardized protocols, a CORBA-based program from any vendor, on almost any computer, operating system, programming language, and network, can interoperate with a CORBA-based program from the same or another vendor, on almost any other computer, operating system, programming language, and network.
Conventional CORBA applications are composed of objects that are individual units of running software that combine functionality and data. Typically, there are many instances of an object of a single type. For example, an e-commerce website would have many shopping cart object instances, all identical in functionality but differing in that each is assigned to a different customer (i.e., client browser), and each contains data representing the merchandise that its particular customer has selected. For other object types, there may be only one instance. As an example, when a legacy application, such as an accounting system, is wrapped in code with CORBA interfaces and opened up to clients on a network, there is usually only one instance.
For each object type, such as the shopping cart mentioned above, a developer using middleware such as CORBA defines an interface in the OMG Interface Description Language (IDL). The interface is a syntax part of a contract that a server object offers to client programs that invoke functionality and access data within that server object. Any client that wants to invoke an operation on the object must use this IDL interface specification (i.e., object specification) to specify the operation it wants to perform, and to marshal arguments (i.e., parameters or data) that the client sends and receives from the server for access to that object. When the invocation reaches the target object, the same interface definition is used there to unmarshal the arguments so that the object can perform the requested data processing operation with the arguments. The interface definition is then used to marshal the results for their trip back to the client, and to unmarshal them when they reach the client destination.
A conventional IDL interface definition is independent of a selected programming language, but maps to all of the popular programming languages via industry standards. As an example, there are standardized mappings from IDL to C, C++, Java, COBOL and other languages.
The use of a middleware-specific interface, such as a CORBA call, that is separate from the middleware implementation, enabled by the IDL, is one essence of middleware such as CORBA and explains how conventional middleware enables interoperability between applications with all of the above noted transparencies. The interface to each object using a conventional middleware platform is defined very strictly. However, CORBA and other middleware platforms hide the implementation of an object (i.e., its running code and its data) from the rest of the system (that is, middleware encapsulates the implementation) behind a boundary that the client application may not cross. Clients access objects only through their advertised CORBA (or other middleware-specific) interface, invoking only those CORBA (or other middleware) operations that the object exposes through its IDL interface, with only those CORBA (or other middleware) parameters (input and output) that are included in the invocation.
FIG. 1 is a prior art illustration of an invocation 90 by a single client process 80 for access to an object implementation 82 using middleware such as CORBA including an IDL stub 84, an object request broker 86, and an IDL skeleton 88. While the instant example uses CORBA as the middleware platform, the example applies to other conventional middleware platforms as well.
Prior to execution, a developer 70 using an IDL compiler 72 compiles an object model specification 74 defined in IDL into client IDL stubs 84 and object skeletons 88, and writes the code for the client 80 and for the object implementation 82. The stubs 84 and skeletons 88 serve as proxies for clients 80 and object 82 (e.g., server), respectively. Because IDL defines interfaces so strictly, the stub 84 on the client side has no trouble meshing perfectly with the skeleton 88 on the server side, even if the two are compiled into different programming languages. If CORBA is the middleware that provides the object request broker (ORB) 86, the CORBA ORB 86 can even be produced from different vendors so long as it conforms to the CORBA standard.
In CORBA, every object instance 82 has its own object reference in the form of an identifying electronic token or string. Clients 80 use the object references to direct their invocations 90, identifying to the ORB 86 the exact instance of an object 82 that the client 80 wants to invoke. Using the shopping cart example, this ensures that the shopping cart object 82 for one client 80 is different from a shopping cart object of another client. The client 80 acts as if it is invoking an operation on the object instance 82, but the client 80 is actually invoking a call on the IDL stub 84 that acts as a proxy to the object 82. Passing through the stub 84 on the client side, the invocation 90 continues through the ORB 86, and the skeleton 88 on the server side, to get to the object implementation 82 where it is executed. FIG. 1 thus shows an invocation when the client is collocated with the server.
FIG. 2 diagrams a remote invocation 92 that occurs over a network. In order to invoke the remote object instance 94, the client 80 first obtains its object reference using, e.g., a naming or trading service or a stringified IOR. To make the remote invocation 92, the client 80 uses the same code used in the local invocation described in FIG. 1, but substitutes the object reference for the remote object instance 94. When the local ORB 86 examines the object reference and discovers that the target object 94 is a remote object, the local ORB 86 routes the invocation 92 out over a network 94 to the remote object's ORB 96.
To identify the correct object 94, the client 80 knows the type of object 94 that it is invoking (e.g., that it's a shopping cart object), and the client stub 84 and object skeleton 88 are generated from the same IDL object model specification 74. This means that the client 80 knows exactly which operations it may invoke, what the input parameters are, and where they have to go in the invocation. Accordingly, when the invocation 92 reaches the target object 94, all parameters are present. Additionally, the local client's 80 ORB 86 and the remote object's ORB 96 operate on a common protocol that provides a representation to specify the identity of the target object 94, its operation, and all parameters (input and output) of every type that they may use. Accordingly, although the local ORB 86 can tell from the object reference that the target object 94 is a remote object, the client 80 does not know the physical operating location of the target object 94. There is nothing in the object reference token obtained by the client 80 that the client holds and uses at invocation time that identifies the location of the target object 94. The token is opaque to the client. This ensures location transparency in order to simplify the design of distributed object computing applications.